1. The Field of the Invention
The present invention relates to an undo infrastructure. More particularly, the present invention relates to methods, systems, and computer program products that automatically generate and track undo information so that the developer of a user interface object need not be responsible for generating and tracking undo information.
2. Background and Related Art
Undo is a familiar feature of many applications. For example, spreadsheets and word processors typically allow data entry, such as adding new data, deleting existing data, cut and paste operations, and data formatting to be undone. Redo is undo's counterpart and in many circumstances is conceptually equivalent to undoing an undo operation. In some implementations, redo may allow the last operation to be repeated. In this application, undo may be used as a generic term encompassing both undo and redo operations.
Visual user interface designers are software that allow a developer to visually represent a user interface and automatically generate at least some of the corresponding source code from the visual representation. Implementing undo in a visual user interface designer presents some unique obstacles. For example, because many different types of objects may be used in a visual user interface designer, implementing undo generally is the responsibility of each object's developer. Many undo implementations operate in a similar fashion, using an “undo unit” to represent a single unit of undoable work. Once created, the undo units are added to a stack and the user is allowed to walk the stack to undo the actions represented by the corresponding undo units.
Frequently, undo units are designed as a toggle. That is, calling undo twice returns back to the beginning state prior to the first call. Due to the complexity of undo, applications generally need to be written from the ground up to support undo. Consider, for example, setting the Text property of a control as illustrated by the pseudo code shown in Table I.
TABLE ItextProp.SetValue(control, “Hello”);To make this action undoable, the action is encapsulated in an object, such as the one illustrated by the pseudo code shown in Table II.
TABLE IIClass TextPropUndoAction { string_newValue; Control_control; public TextPropUndoAction(Control control, string newValue) {  _control = control;  _newValue = newValue; } public void DoAction( ) {  string oldValue = (string)textProp.GetValue(control);  textProp.SetValue(control, _newValue);  _newValue = oldValue; }}
Traditionally, a developer then makes use of the this class as shown by the pseudo code illustrated in Table III.
TABLE IIITextPropUndoAction a = new TextPropUndoAction(control, newValue);a.DoAction( );undoStack.Push(a);While the implementation illustrated in Tables II and III works, it is easy for developers to break. Notice that TextPropUndoAction is fragile—the state of the control must be consistent if this object is going to correctly undo the action. For example, if there is a single piece of code somewhere that changed the control text property directly (i.e., not as shown in Table III, but simply as shown in Table I) TextPropUndoAction will break. This happens all too often practice, perhaps when an inexperienced programmer fails to consider how a particular change will impact undo. To further complicate the problem, if an undo action fails for some reason, implementing the correct fail semantics for each class can be a daunting task. Traditional undo implementations also are unable to provide undo support for third-party objects that do not implement undo, as shown for example, in Table II.
Accordingly, methods, systems, and computer program products that automatically generate and track undo information so that the developer of a user interface object need not be responsible for generating and tracking undo information, are desired.